Adding error handling is not a chore, chores are things like updating README, dependencies, code syntax (without changing behaviour).

This adds a new feature to the app, it changes the behaviour of the app, in the form of showing error messages for cases that would otherwise fail silently, giving no hint to the user that things are broken.

Semantically, I think this commit should be a feat:

This is important in contexts where an app may have automated release scripts. A chore commit will be ignored by the release script since it, semantically, does not come with any changes to the behaviour of the application. A fix commit would trigger a patch version bump (0.0.X). Semantically, a fix corrects the (buggy) behaviour of an already existing feature. A feat commit would trigger a minor version bump (0.X.0), meaning new functionality has been added to the app. Any version change would trigger a new release of the application.

(to complete the above, a fix!: or feat!: commit would represent a bug fix or feature that causes breaking changes to the application API, triggering a major (X.0.0) version bump.)

@martinstark Do I need do create a new brach that is named correctly or is it enough to just rename the PR? So that the branch and the commit still have the faulty naming or should I redo the brach and the commit to get it right throughout?

it's fine if you just rename the commit with git commit --amend and force push here, it's the git history that matters